DS713+ TP-link Link aggregation

Добрый день!

Может кто нибудь сталкивался с настройкой Link aggregation при такой конфигурации?

NAS - Synology 713+

Коммутатор - TP-link TL-SG1016DE - управляемый с веб интерфейсом

Сеть гигабитная.

Настроил port trunk на коммутаторе (в веб интерфейсе - System-Switching-Port Trunk, на synology создал соединение IEEE 802.3ad dynamic link aggregation.)

Включаю два провода от synology в коммутатор - он пропадает из сети и не пингуется.

Один провод убираешь - появляется.

неужели не получится их настроить на совместную работу?

Добрый день!

Может кто нибудь сталкивался с настройкой Link aggregation при такой конфигурации?

NAS - Synology 713+

Коммутатор - TP-link TL-SG1016DE - управляемый с веб интерфейсом

Сеть гигабитная.

 

Настроил port trunk на коммутаторе (в веб интерфейсе - System-Switching-Port Trunk, на synology создал соединение IEEE 802.3ad dynamic link aggregation.)

 

Включаю два провода от synology в коммутатор - он пропадает из сети и не пингуется.

Один провод убираешь - появляется.

неужели не получится их настроить на совместную работу?

А зачем ?

У вас в сети все остальные устройства тоже поддерживают Link aggregation ??

А зачем ?

У вас в сети все остальные устройства тоже поддерживают Link aggregation ??

А они должны? :blink: Я думал, что это просто логическое объединение двух физических каналов на уровне коммутатора и пользователям в сети (компьютеры, принтеры, камеры и тд) в принципе все равно и они не должны разницы видеть...

А они должны? :blink: Я думал, что это просто логическое объединение двух физических каналов на уровне коммутатора и пользователям в сети (компьютеры, принтеры, камеры и тд) в принципе все равно и они не должны разницы видеть...

Link aggregation делают что бы повысить скорость канала условно в 2 раза.

Но для этого на другом конце ( компьютер, медиапроигрыватель, телевизор, еще один NAS и т.д.) тоже поддерживали Link aggregation.

И все устройства на их пути такие как свичи тоже поддерживали Link aggregation.

А иначе какой толк в Link aggregation между Сино и Свичем ???

Нет, конечно если вы поднимите Link aggregation между сино и свичем, то устройствам будет все равно, они так же будут работать на заявленной для них скорости.

Вот только смысл в Link aggregation теряется.....

У вас в сети все остальные устройства тоже поддерживают Link aggregation ??

вот тут можно пояснить, почему это необходимое условие?

вот тут можно пояснить, почему это необходимое условие?

А кто сказал что это необходимое условие ?

Всего лишь было сказано что без онного смысла в Link aggregation нет, о чем и написано чуть выше.

А кто сказал что это необходимое условие ?

Всего лишь было сказано что без онного смысла в Link aggregation нет, о чем и написано чуть выше.

Ну так почему же в этом смысла нет?

сидор, не порите чухню)

топикстартер, транк это для 802.1q, а не для 802.3ad. агрегации, иэерченела, линк агригейшен груп и тд там не заявлено.

Link aggregation делают что бы повысить скорость канала условно в 2 раза.

Но для этого на другом конце ( компьютер, медиапроигрыватель, телевизор, еще один NAS и т.д.) тоже поддерживали Link aggregation.

И все устройства на их пути такие как свичи тоже поддерживали Link aggregation.

А иначе какой толк в Link aggregation между Сино и Свичем ???

Нет, конечно если вы поднимите Link aggregation между сино и свичем, то устройствам будет все равно, они так же будут работать на заявленной для них скорости.

Вот только смысл в Link aggregation теряется.....

Нет, не теряется, или я чего-то не понимаю...

Ведь у нас несколько устройств может работать с сино одновременно, без линк агрегэйшна - скорость будет ограничена на стороне сино, а с линк агрегэйшн - этот лимит будет в два раза (примерно) выше.

скажем - у нас в гигабитной сети три устройства: сино, комп1 и комп2.

Оба компа тянут с сино файло на максимальной гигабитной скорости.

Без ЛА - скорость будет ограничена на сино гигабитным лимитом, на компы, на каждый, достанется по половине гигабитной полосы.

А с ЛА только на стороне сино - каждый комп получит по полноы гигабитке, а сино будет отдавать файло с удвоенной скоростью.

Понятно, что ситуация упрощена и числа округлены, но идея ЛА именно в том, что ее часто достаточно только на стороне сервера, потому что требования к скорости сети у сервера выше - он может обслуживать несколько клиентов одновременно.

Честно говоря непонятно из-за чего разгорелся весь этот сыр-бор. Ключевой вопрос - Коммутатор - TP-link TL-SG1016DE поддерживает 802.3ad или нет? Если да, то Link Aggregation на сино поднимать имеет смысл. Ну а клиенты 802.3ad - это в большинстве своём конечно не компы и ноуты, а сервера типа сино с несколькими гигабитными сетевухами. Но собственно никто также не мешает напихать несколько гигабитных сетевух в тот же комп ...

PS TL-SG1016DE - Поддерживаемые стандарты и протоколы:

IEEE 802.3, IEEE 802.3u, IEEE 802.3ab, IEEE 802.3x, IEEE 802.1q, IEEE 802.1p

сидор, не порите чухню)

Поясните , где я ошибаюсь ?

И что мне даст канал в 2000Мб/с между роутером и Сино ?

http://s018.radikal.ru/i509/1504/ae/b0543aa96a41.jpg

Поясните , где я ошибаюсь ?

И что мне даст канал в 2000Мб/с между роутером и Сино ?

http://s018.radikal.ru/i509/1504/ae/b0543aa96a41.jpg

Я же вроде пытался выше сказать... Оно тебе даст возможность одновременно двум клиентам тянуть с/на синолоджи файло со скоростью до 1000 Мбит/сек каждому. Ну или любому (>1) количеству клиентов одновременно со скоростью 1) не более максимальной для данного клиента (типично 1000 Мбит/сек для гигабитной сетки) или 2) (суммарно со всех клиентов) максимальной для для твоего сервера (в твоем случае - 2000 Мбит/сек), в зависимости что меньше. Скажем - три клиента одновременно по ~650 Мбит/сек, или четыре клиента по 500, иди пять по 400, ну и так далее. А без бонда этот второй лимит был бы в два раза меньше, хотя первый, конечно же, остался бы такой же.

Поясните , где я ошибаюсь ?

И что мне даст канал в 2000Мб/с между роутером и Сино ?

Между сино и роутером не даст ничего. Между сино и 802.3ad-совместимым свичём либо даст пиковую разгрузку сети при одновременном активном сетевом трафике нескольких гигабитных клиентов, либо при наличии одного компа с несколькими сетевухами и поднятой на нём аггрегацией даст возможность ускориться этому самому компу.

PS Парадокс, но каждый прав по-своему. А возвращаясь к ТC - надо убедиться в том что коммутатор - TP-link TL-SG1016DE действительно поддерживает 802.3ad - на сайте это как-то неявно и сумбурно.

топикстартер сдох а флейм идет)

у меня 2 лаг, один к сино, другой с свичу в зале. зачем это надо? не извесно, просто рас есть в железках че бы не использовать. мерять попугаев мне линиво)

Это не совсем флейм....

Тема Link Aggregation интересна сама по себе...

polanat SergeS скажите у вас много "честных" гигабитных устройств ( а не медиаплееров с якобы гигибитными портами ) которые реально тянут с сино по гигибиту одновременно ?

mowgli

Ваше объяснение, чуть выше, необходимости Link Aggregation еще больше тянет на чухню

На самом деле sidor_ii прав и с поддержкой я этот вопрос выяснял полгода назад. Ну как выяснял..... Говна на них было вылито тонны и хотелке таки был дан ход.

В текущей версии используется балансировка по MAC. Так что да - клиент должен иметь на борту карточку с двумя либо с четырмя портами, где МАКи идут последовательно, один за другим. Тогда ощутите "приход". Разумеется, карточка должна уметь 802.3ad.

Можете провести эксперимент - пропишите последовательные маки на разных компах и запустите одновременное копирование на Сино. Только в этом случае увидите честный гигабит на каждой сетевухе компов.

Для дома фишка абсолютно бесполезная и я, например, давно от неё отказался.

А то, что вы все хотите, будет реализовано в DSM 5.2 - Adaptive Load Balancing.

скажите у вас много "честных" гигабитных устройств ( а не медиаплееров с якобы гигибитными портами ) которые реально тянут с сино по гигибиту одновременно ?

А причём тут мы? Ну допустим у меня у всего немедиаплеерного парка - действительно гигабитные сетевухи. Однако пока на хозяйстве - небондовый сино. Тем не менее "ожидаю" 4-дисковик с 2-мя гигабитными портами. А посему тема "Link Aggregation" действительно интересна, ибо из сино-хелпа вычитываем четыре сино-режима:

1. Адаптивное распределение нагрузки (Adaptive Load Balancing): Этот режим оптимизирует сетевой трафик, принимаемый и отправляемый вашим устройством Synology NAS, если коммутатор поддерживает Link Aggregation. Чтобы избежать непредвиденных ошибок, не включайте Link Aggregation на коммутаторе, даже если эта функция поддерживается им. (Доступен только в DSM 5.2)

2. Динамический режим IEEE 802.3ad Link Aggregation: Этот режим оптимизирует сетевой трафик, принимаемый и отправляемый вашим устройством Synology NAS, и требует включения на коммутаторе (коммутаторах) динамического режима IEEE 802.3ad Link Aggregation (LACP, 802.1AX). Если используется несколько коммутаторов, они должны быть наращиваемыми и правильно настроенными.

3. Распределение XOR: Этот режим позволяет сбалансировать сетевой трафик, принимаемый и отправляемый вашим устройством Synology NAS, и требует включения на коммутаторе (коммутаторах) статического режима Link Aggregation. Если используется несколько коммутаторов, они должны быть наращиваемыми и правильно настроенными. Если Link Aggregation не поддерживается коммутатором, трафик, отправляемый вашим устройством Synology NAS, все равно можно сбалансировать. При помощи этого режима можно выявить потерю соединений, но не причину (например, отсоединение кабелей Ethernet или неправильная настройка коммутатора). (Доступен только в DSM 5.2)

4. Активно/Режим ожидания: Этот режим обеспечит вашему устройству Synology NAS отказоустойчивость сети (network fault tolerance). То есть, в случае сбоя активного сетевого интерфейса подключение к сети обеспечит один из других портов локальной сети. Можно выбрать этот режим без настройки коммутатора или при помощи коммутатора, поддерживающего IEEE 802.3ad Link Aggregation.

PS Да, помощь таки была нужна ТС - пусть отпишется чего решил - к чему пришёл

Это не совсем флейм....

Тема Link Aggregation интересна сама по себе...

polanat SergeS скажите у вас много "честных" гигабитных устройств ( а не медиаплееров с якобы гигибитными портами ) которые реально тянут с сино по гигибиту одновременно ?

У меня в сети три полноценных десктоп компьютера и второй сино для бэкапов, все по проводам, все по честному гигабиту. Все в общем то могут тянуть по гигабиту, включаются одновременно почти каждый день, минимум по несколько часов в день. А вот три моих медиаплеера - все вроде с 100 мегабитными портами ;-). Ну и всякие мелочи типа принтера (кстати тоже гигабитного), жменька постоянных wifi устройств плюс приходящие в гости, плюс пара тестовых компов, плюс камеры, плюс хвох, плюс тв, плюс совсем уж мелочи типа пары ардуин... Короче мне бы линк агрегэйшн бы пригодился, но пока нету. А если у тебя в сети всего три с половиной устройства, из них только два (сино и комп) гигабитники - то тогда, да, пользы от линк агрегэйшна нету, он дает выигрыш только при одновременном доступе с разных точек.

На самом деле sidor_ii прав и с поддержкой я этот вопрос выяснял полгода назад. Ну как выяснял..... Говна на них было вылито тонны и хотелке таки был дан ход.

 

В текущей версии используется балансировка по MAC. Так что да - клиент должен иметь на борту карточку с двумя либо с четырмя портами, где МАКи идут последовательно, один за другим. Тогда ощутите "приход". Разумеется, карточка должна уметь 802.3ad.

Можете провести эксперимент - пропишите последовательные маки на разных компах и запустите одновременное копирование на Сино. Только в этом случае увидите честный гигабит на каждой сетевухе компов.

Для дома фишка абсолютно бесполезная и я, например, давно от неё отказался.

 

А то, что вы все хотите, будет реализовано в DSM 5.2 - Adaptive Load Balancing.

Не совсем понятно в чем он таки прав? Я у него уже как минимум дважды спрашивал, почему он так думает, и ответа пока не получил, если он так думает из-за того, что в сино-реализации какойто хомут, то неплохо бы сразу было бы об этом сказать, тип "я так думаю потому что у сино баг, не позволяющий использовать преимущества ЛА"...

Мы говорим о линк агрегэйшн вообще или о конкретной реализации в синолоджи, которая имеет какой то баг? В документации синолоджи нет требования последовательных маков, ничего не сказано об отличиях ихней реализации от стандартной. Если речь таки о баге - то неплохо бы это озвучить на третий день нашего общения ;-), к тому же - даже если этот баг таки имеет место быть - его вполне могут поправить в следующих версиях.

В документации синолоджи нет требования последовательных маков, ничего не сказано об отличиях ихней реализации от стандартной.

Вот именно за это они и получили свою порцию говна.

И это не баг, просто так у них реализовано - балансировка по MAC.

Но такой "маленький" нюанс совсем не лишним было бы подвесить как баннер охренительно огромными буквами рядом с коммутаторами в списке совместимости. Ну это как минимум.

А если бы китайцы не были бы такими ленивыми, могли бы предоставить настройки пользователю на выбор: "balancing MAC/IP".

Уже б легче жилось.

Но это ж надо реализовать! Глядишь, к седьмой версии и созреют.

Но это ж надо реализовать! Глядишь, к седьмой версии и созреют.

Да сколько тут до седьмой осталось ;-), моей первой версией dsm была, если не ошибаюсь, 2.3. Может я к тому времени как раз и правильный свитч куплю ;-)))

суббота все таки, вот и пропал)

У меня в сети бывает до 15 компов, все с гигабитной скоростью работают с сервером, поэтому и думал как то ему облегчить задачу.

Посмотрел на сайте по коммутатору - явно не заявлен стандарт 802.3ad( видимо не поддерживает. При этом есть какое-то агрегирование каналов, не понятно что за зверь...

Когда выйдет 5.2 прошивка стабильная - попробую другие режимы на сино повыбирать)

И это не баг, просто так у них реализовано - балансировка по MAC.

Но такой "маленький" нюанс совсем не лишним было бы подвесить как баннер охренительно огромными буквами рядом с коммутаторами в списке совместимости. Ну это как минимум.

И всё таки я так до конца и не понял про баг-фичу с последовательными маками. Возьмём простую связку из трёх устройств - сино с LA + 802.3ad-совместимый свич + комп с 2-мя сетевухами. На всех трёх устройствах выделено по два сетевых порта с разными маками. Чтобы протащиться именно на компе с LA на DSM 5.1 надо чтобы 2 сетевухи компа имели последовательные маки? Так? А тогда, позвольте спросить про промежуточное у-во, сиречь, 802.3ad-совместимый свич - то есть выбранные его 2 порта под аггрегацию тоже должны быть с последовательными маками или здесь это не важно? Вопрос в контексте, что сино с компом соединены не напрямую а через свич (хотя эксперимент с прямым соединением сино-компом с 2-мя сетевухами тоже возможен).

Вторая часть вопроса - мы опять как-то отвлеклись от основной темы TC - у него 15 гигабитных компов и вставлять дополнительные сетевухи в них (или хотя бы в свой единственный) он явно не собирается. А посему резонный вопрос - как именно работает (и работает ли вообще) в DSM 5.1 минимум 2-й из заявленных режимов (4-й - network fault tolerance - полагаю что и так работает - проверить легко, оторвав 2-й шнурок):

2. Динамический режим IEEE 802.3ad Link Aggregation: Этот режим оптимизирует сетевой трафик, принимаемый и отправляемый вашим устройством Synology NAS, и требует включения на коммутаторе (коммутаторах) динамического режима IEEE 802.3ad Link Aggregation (LACP, 802.1AX). Если используется несколько коммутаторов, они должны быть наращиваемыми и правильно настроенными.

PS То есть на текущей сино-версии DSM 5.1 в пике суммарно 15 компов с "непоследовательнами" маками могут рассчитывать на 2 гигабита или нет?

И всё таки я так до конца и не понял про баг-фичу с последовательными маками. Возьмём простую связку из трёх устройств - сино с LA + 802.3ad-совместимый свич + комп с 2-мя сетевухами. На всех трёх устройствах выделено по два сетевых порта с разными маками. Чтобы протащиться именно на компе с LA на DSM 5.1 надо чтобы 2 сетевухи компа имели последовательные маки? Так? А тогда, позвольте спросить про промежуточное у-во, сиречь, 802.3ad-совместимый свич - то есть выбранные его 2 порта под аггрегацию тоже должны быть с последовательными маками или здесь это не важно?

Это не важно.

(хотя эксперимент с прямым соединением сино-компом с 2-мя сетевухами тоже возможен).

Нет, невозможен для агрегации этого типа.

PS То есть на текущей сино-версии DSM 5.1 в пике суммарно 15 компов с "непоследовательнами" маками могут рассчитывать на 2 гигабита или нет?

Нет, не могут. И даже с последовательными - тоже не могут. Ибо если запустить копирование одновременно с первого компа и третьего - уже непоследовательные маки получаются.

На клиентах должны стоять типа таких сетевух http://market.yandex.ru/product/6988912?hi...95&clid=502

или аналогичные двухпортовые, которые точно также тыкаются в свитч 802.3ad и порты объединяются в группы. Потому свитчу посрать какие там маки. Он не просто так позиционируется как "с поддержкой 802.3ad".

Нет, не могут. И даже с последовательными - тоже не могут. Ибо если запустить копирование одновременно с первого компа и третьего - уже непоследовательные маки получаются.

На клиентах должны стоять типа таких сетевух http://market.yandex.ru/product/6988912?hi...95&clid=502

или аналогичные двухпортовые, которые точно также тыкаются в свитч 802.3ad и порты объединяются в группы. Потому свитчу посрать какие там маки. Он не просто так позиционируется как "с поддержкой 802.3ad".

А остался официальный ответ поддержки, где они про это пишут? Или где они вообще об этом пишут?

А остался официальный ответ поддержки, где они про это пишут? Или где они вообще об этом пишут?

Они это пишут у меня в почтовом ящиге. Переписка была в июле прошлого года, сохранилось не всё.

Цитирую только основные ответы в порядке хронологии, чтобы была понятна основная мысль:

http://s017.radikal.ru/i410/1504/7d/890395a9059d.jpg

http://s012.radikal.ru/i320/1504/d4/7306b4693653.jpg

http://s017.radikal.ru/i444/1504/4a/704efe4233e1.jpg

Только после этого я получил честный гигабит на каждый комп (при одновременном копировании).

Потом я брал у знакомого броадкомоскую сетевущку с 4-мя портами на комп - да, всё реально работало.

Но от агрегации я отказался давно, думаю по понятным причинам.

Гораздо более эффективно используется разделение трафика по службам. В 5.1 это реализовано и прекрасно работает. Получается даже более эффективно, чем LACP. Для этого всего лишь нужно:

http://s011.radikal.ru/i318/1504/f0/cb1239defef6.jpg

И назначьте на своих 2-х или 4-х интерфайсах Синолоджи IP-адреса из одной подсети, т.е. 192.168.1.*

Можно использовать самый обычный свитч.

Всё.

После этого получаем вот что:

http://s019.radikal.ru/i601/1504/40/aadd05ca9b99t.jpg

Только после этого я получил честный гигабит на каждый комп (при одновременном копировании).

 

<...>

 

Гораздо более эффективно используется разделение трафика по службам. В 5.1 это реализовано и прекрасно работает. Получается даже более эффективно, чем LACP.

Все понятно, коротко и доходчиво, спасибо.

И за lacp и за разделение траффика, я об этом вообще не думал... Я и так не сильно торопился покупать умеющий это свич. А сейчас так и вовсе "тарапися не буду" ;-)

хм. а почему тогда при живом лаге уже года 3 на дсмах начиная с 3.2 трафик бонда делится на два интерфейса?

bond0 Link encap:Ethernet HWaddr 00:11:32:0D:5F:A5

inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0

inet6 addr: fe80::211:32ff:fe0d:5fa5/64 Scope:Link

UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1

RX packets:1743748887 errors:0 dropped:0 overruns:0 frame:0

TX packets:3191753125 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:286365040542 (266.6 GiB) TX bytes:4509022350437 (4.1 TiB)

eth0 Link encap:Ethernet HWaddr 00:11:32:0D:5F:A5

UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1

RX packets:867774090 errors:0 dropped:0 overruns:0 frame:0

TX packets:3043925175 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:132506361616 (123.4 GiB) TX bytes:4298749473979 (3.9 TiB)

Interrupt:17 Memory:febe0000-fec00000

eth1 Link encap:Ethernet HWaddr 00:11:32:0D:5F:A5

UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1

RX packets:875974797 errors:0 dropped:0 overruns:0 frame:0

TX packets:147827950 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:153858678926 (143.2 GiB) TX bytes:210272876458 (195.8 GiB)

Interrupt:16 Memory:feae0000-feb00000

хм. а почему тогда при живом лаге уже года 3 на дсмах начиная с 3.2 трафик бонда делится на два интерфейса?

Ой, как интересно ;-), так оно работает али не работает?

хм. а почему тогда при живом лаге уже года 3 на дсмах начиная с 3.2 трафик бонда делится на два интерфейса?

Делиться-то оно делится без проблем. У меня делился на 4 интерфейса. А общая скорость при этом как?

Случайно не ограничивается гигабитом? Подозреваю, что да.

Оно работает как fault tolerance.

Всем привет, имеется RS814 + управляемый коммутатор HP 1820 48G

подключил оба Ethernet порта в свич, до обновления на новую прошивку скорость передачи была около 100 мб. в секунду, сейчас скорость упала до 10 мб. сек. В настройках сети показывает что поднят канал IEEE 802.ab, на свиче соответственно это настроено как надо через Trunk, иначе эта фича на Synology не поднималась. Пробовал так же через новую опцию XOR (для этого в транке прописывал Static), и другие настройки, скорость не увеличивается.

До этого стояла версия прошивки 4.0 сейчас DSM 6.2.1-23824 Update 1

настройки коммутатора

http://prntscr.com/lqex20

http://prntscr.com/lqffi0

настройки DSM

http://prntscr.com/lqf9vo

Самый прикол что я уже просто переключил в отказоустойчивую работу и всё-равно скорость передачи плавно падает с 30 до 10 мб. сек... Что за новые прошивки такие???